Public Key Infrastructure (PKI) is based on public-key cryptography, mainly for solving the issue of key certification, that is, to whom a key pair (a private key and a public key) belongs. PKI implements key certification using digital certificates issued by Certification Authorities (CAs), which publish the owner information of key pairs, and provide security assurance to digital signature and related security services in computer networks.
CA is a third party responsible for signing digital certificates, and is an entity trusted by communication parties based on PKI. A digital certificate (or simply referred to as a certificate) binds a public key and the owner's identity of the corresponding private key by CA's digital signature (or simply referred to as signature). Using a digital certificate, PKI properly proves who owns the key pair. A digital certificate has a limited validity period. After expiration, a digital certificate is no longer valid and the binding relationship represented by the digital certificate no longer exists.
A digital certificate can be invalidated and its binding relationship terminated before its expiration due to compromises of the private key, changes of the identity information of the certificate subject (i.e., the owner of the key pair), or breaches of public key algorithms, etc. The procedure is called certificate revocation. PKI lacking certificate revocation would face significant security threats. For example, if Alice's private key is stolen by an attacker before her certificate expires, and if any certificate revocation mechanism did not exist, the attacker could impersonate Alice, login to Alice's applications and decrypt confidential information sent to Alice by others.
The basic process of publishing certificate revocation information is as follows. A CA in PKI system gathers the identifications (typically certificate serial number) of currently revoked certificates into a single list, and releases the list to all PKI users. In order to prevent counterfeiting and tampering, CA needs to digitally sign its list. This CA-signed list that contains the identities of currently revoked certificates is called Certificate Revocation List (CRL).
The basic process of using CRL to check certificate revocation status involves the following:
a. Firstly, the certificate relying party (i.e. an entity that uses someone else's certificate for encrypted communication, authentication, digital signature verification, or other security operations) can query and download CRL from PKI repository, and verify the validity of CRL itself including checking whether CRL's digital signature is correct and whether CRL is within its validity period.
b. The certificate relying party then construct a list of certificate serial numbers of revoked certificates. The list of certificate serial numbers of revoked certificates can be constructed differently for various CRL mechanisms. For basic CRL mechanism, one can obtain, from each individual CRL file, a complete list of certificate serial numbers of currently revoked certificates.
c. The certificate relying party checks whether a certificate has been revoked. The certificate relying party searches the list of certificate serial numbers of currently revoked certificates to examine if the serial number of the certificate being verified is listed therein. If it is in the list, it indicates that the certificate has been revoked; otherwise, it shows that the certificate has not been revoked.
CRL has limited timelines. Considering that certificate revocation status changes over time and is unpredictable, the information in CRL must also be subject to change in order to correctly respond to the latest situation. Notice that certificates are only to be revoked when a few security incidents occur, and in most cases a certificate will keep valid, CA generally publishes CRL reflecting the latest certificate revocation information in a periodical manner. The period of updating CRL (which implying the timelines requirement for certificate revocation information) is set by PKI system according to the security requirements of different applications of certificate relying parties. For example, the update period of CRL for large-value electronic transactions can be set as an hour, while that for daily email protection can be set as 48 hours. Certificate relying parties need to have timely accesses to CRL.
Certificate relying parties can learn about certificate revocation status of multiple certificates together from a single CRL file. This service model is suitable for situations in which certificate relying parties simultaneously communicate with many parties and thus need to verify a lot of certificates at the same time. For example, for an online game server that requires users to log in using certificates, the server only needs to periodically download the latest CRL from PKI repository, which enables it to check the revocation status of all users' certificates. It is unnecessary for the server to communicate with PKI repository each time when a certificate is being verified.
CA provides various patterns of downloading CRL such as delta CRL and redirect CRL, besides solely downloading a single CRL file. The certificate relying parties need to configure themselves separately in accordance with the CRL service patterns of different CAs. The method of downloading CRL is sometimes directly specified in a certificate as a certificate extension, which allows the certificate relying parties to automatically learn appropriate PKI repository and download CRL from that. However, the way of downloading CRL is sometimes not involved in a certificate; the certificate relying parties then need to manually configure the download methods on each individual machine, which is troublesome. Moreover, in some cases, although the method has been involved in a certificate, the specific method is not supported by the computer systems of certain certificate relying parties. For example, LDAP protocol is not universally supported by all certificate relying parties. The above described situations bring extra complexity to PKI clients designing and implementation, and confusion to application systems and users of certificate relying parties. Additionally, the certificate relying parties typically begin to download CRL after they have received certificates, the relatively large CRL files (sometimes larger than 1 M byte) can cause delay (because subsequent operations cannot get started before the CRL download is completed). Such delay can be avoided if download can occur in advance.
Virtualization technology has been widely applied since AMD and Intel have successively launched products supporting hardware virtualization. Using virtualization, enterprises can reduce cost of capital and office space requirement, and improve availability, flexibility and security of business. Virtualization technology enables users to run multiple virtual machines (referred to as VMs) on a physical computer, wherein the physical computer is called the host. An important component of the virtualization platform is the virtual machine monitor (VMM). Its main function is to manage the resources on the host and to enable the virtual machines to run on the host to share the same set of host resources. Virtualization platform provides the capability of a unified management of multiple VMs. Virtualization technology divides the VMs from the differences of lower-level implementation. The high-level VMs can take advantage of the lower-level resources in an unified manner, regardless the implementation method of the lower-level resources (which can be implemented by software or hardware, or by different types of hardware).